Organizations, especially businesses, have been adopting large scale computer systems based on message-oriented enterprise application integration (EAI) in greater and greater numbers. Tremendous value is realized by an organization from re-use of systems, sharing of resources, and standardization of applications. FIG. 1 is a high level block diagram of an exemplary EAI environment 100. The environment 100 is assembled around a central bus, such as an enterprise message bus 102, to which various enterprise systems or applications 104A, 104B and 104C are attached. The systems 104A, 104B and 104C may be incompatible as discrete systems (that is, they may not be able to exchange data as stand alone systems). However, the message bus 102 allows the systems 104A, 104B and 104C to exchange transactions or messages with each other using a common message format, such as the frequently used Extensible Markup Language (XML). Adapters between a system 104 and the bus 102 “translate” messages between the common message format and whatever format is used by a particular system 104. Thus, transactions may be exchanged among disparate systems. In fact, some environments may include over a thousand individual applications, integrated and working together only through the use of an EAI message bus.
Certain systems 104D may not be currently attached to the bus 102 due to undergoing installation or maintenance or being unavailable for any of various other reasons. Other systems or applications 106A and 106B are considered “off-bus” and communicate with each other through direct, point-to-point messages which may have a proprietary format. While not directly attached to the EAI environment 100, the off-bus applications 106A and 106B may be indirectly coupled to the EAI environment 100 through an existing EAI system, such as the system 104C.
FIG. 2A is a system diagram of a portion 200 of an exemplary EAI system in a business environment. The illustrated portion 200 includes an order entry system or application 202, a credit check system 206 and an order management system 210. Each system 202, 206, 210 is attached to an enterprise bus 214 through a bus adapter 204, 208, 212, respectively. FIG. 2B is a corresponding transaction diagram which illustrates the sequence of transaction processing in the system portion 200. Briefly, when a new purchase order is received from a customer, it is entered into the order entry system 202 where a new order is created (step 220). Specific information about the new order (such as customer name, transaction amount and other transaction terms) is transmitted through the bus 214 to the credit check system 206 (step 222). If credit is approved by the credit check system 206 (step 224), an order validation is transmitted back to the order entry system 202 (step 226), enabling the order to be further processed (step 228). In the foregoing brief synopsis, the order management system 210 does not participate. However, the order management system 210 may subsequently receive information messages from the order entry system 202 to enable the order to be filled. The order management system 210 may exchange messages with an inventory management system (not shown) and, eventually, an accounts management system (also not shown). It will be apparent that in a large company, thousands of messages may be exchanged over the bus each day. It will also be apparent that proper operation of the entire enterprise may be critical to a company's continued existence. Thus, suitable testing of enterprise applications is also critical.
It is well known for computer systems and applications to be tested at least upon installation and upgrade. Periodic testing may also be performed. In an EAI environment, it is typical to test individual applications to ensure their correct operation. FIG. 3 is a high level block diagram of the exemplary EAI environment 100 of FIG. 1 with an application 104A being tested through a test tool 300 (although not shown in FIG. 3, the other applications would be similarly tested). One type of tool which may be used to test an application is a GUI (graphical user interface) based tool. A GUI test tool accesses the target application through the target application's user interface and can, therefore, direct activity or collect test results only to the same extent as the target application itself has access to the rest of the enterprise environment. Thus, numerous aspects of a transaction are out of reach. Moreover, if using a GUI-based test tool, dozens, or even hundreds, of lines of code, may be necessary to navigate an order entry screen and fill in each text box, radio button and tab of the order form before the ‘save” button is pressed to execute the test. Then, additional coding may be necessary to compute and enter a simulated response into another screen. And, with numerous transactions out of reach of a GUI-based tool associated with one particular application, similar tools must be used to test the other applications in the environment; however, only individual applications are able to be tested, not any interactions among applications.
Another type of tool which may be used is an application programming interface (“API”) based test tool. However, typical API-based tools have similar drawbacks to those of GUI-based test tools. One particular drawback is the need for extensive programming in order to build simulations.
Thus, conventional test tools only test an individual component of an enterprise from the “outside”; that is, from the perspective of the end user or the application interface. For testing of full business processes in an EAI enabled environment, all component systems and applications should be available and functioning correctly (alternatively, unavailable systems should be replaced by appropriate simulators or advanced EAI testing capabilities). But, as the number of individual applications in an enterprise environment increases, the number of combinations of possible side effects to each possible group of interacting applications rises factorially. Unfortunately, the complexity and scale of large EAI environments makes manual testing prohibitive. And, neither automated testing from the perspective of the enterprise itself, with full end-to-end business process testing, nor automated integration testing has been available.
Thus, a need remains for automated, end-to-end testing of business processes across an EAI environment. Moreover, creating and executing tests should be relatively easy and include repeatable regression testing, results validation should be flexible and pass/fail results should be easily identified.